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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



£75/ 



3GPP TS 29.31 1 version 8.2.0 Release 8 6 ETSI TS 1 29 31 1 V8.2.0 (201 1 -1 0) 



Scope 



The present document specifies the protocol details of service level interworking between Instant Message as specified 
in OMA-TS-SIMPLE_IM [4] using the 3GPP IP Multimedia CN subsystem and the Short Message Service over both 
legacy CS/PS network as specified in the 3GPP TS 23.040 [2] and a generic IP Conectivity Access Network (IP -CAN) 
as specified in the 3GPP TS 24.341 [5]. These include: 

Procedures to implement service level interworking between IM and SM. 

Enhancement of the IP-SM-GW as an Application Server to support service selection, authorization and 
mapping between IM and SM protocols. 

Interaction between service level interworking and transport layer interworking. 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following 
apply. A term defined in the present document takes precedence over the definition of the same term, if any, in 
3GPPTR 21.905 [1]. 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.204 [6], 
subclause 3.1 apply: 

SMSIP MESSAGE 
Instant Message 

For the purposes of the present document, the following terms and definitions given in RFC 3261 [10] apply. 

Header 

Header field 

Request 

Response 

Status-Code (see RFC 3261 [10], subclause 7.2) 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.002 [11], 
subclauses 4.1.1.1 and 4a.7 apply: 

Home Subscriber Server (HSS) 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.040 [2] apply: 

WVG Object 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.228 [12], 
subclauses 4.3.3.1, 4.3.6 and 4.6 apply: 

Serving-CSCF (S-CSCF) 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
3GPPTR 21.905 [1]. 

AS Application Server 

IM Instant Message 

IMDN Instant Message Disposition Notification 

IP-SM-GW IP-Short-Message-Gateway 

SM Short Message 

UDH User Data Header 

WVG Wireless Vector Graphics 
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4 Overview of service level interworking for messaging 

services 

4.1 Introduction 

The service level interworking for messaging services provides the interworking function between Instant Message and 
the Short Message to enable the communication between SM UE and Instant Message UE. The architecture for service 
level interworking is specified in 3GPP TS 23.204 [6]. 

4.2 Service level interworking between SM and IM 

In order to provide the service level interworking between SM and IM, the following protocol mapping functionalities 
defined in 3GPP TS 23.204 [6] shall be supported: 

Instant Message mapped to Short Message over CS/PS; 

Instant Message mapped to Short Message over IP; and 

- Short Message mapped to Instant Message. 

4.3 Interaction with transport layer interworking 

Both transport layer interworking and service level interworking shall be provided by IP-SM-GW. The interaction 
between transport layer interworking and service level interworking depends on the user subscription and authorization, 
on the UE capabilities, and on operator policy. 

If a user only subscribes to either transport layer interworking or to service level interworking, only procedures defined 
for the subscribed interworking shall be performed by the IP-SM-GW. 

If a user subscribes to both transport layer interworking and service level interworking, but the user is only authorised 
for one of the interworking when the message is processed, only the authorised interworking shall be performed by the 
IP-SM-GW. 

If a user subscribes to both transport layer interworking and service level interworking, and is authorised for both, the 
behaviour of the IP-SM-GW depends on the specific scenario, on the registered capabilities of the UE, and finally is 
defined by operator policy and user preferences. 



5 Functional entities 
5.1 Application Server (AS) 

An AS may implement the role of an IP-SM-GW (see subclause 6.1). 

6 Roles 

6.1 IP-Short-Message-Gateway (IP-SM-GW) 
6.1.1 General 

An IP-SM-GW is an entity that provides the service level interworking for: 

delivering a Short Message or concatenated Short Messages as an Instant Message; 
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delivering concatenated Short Messages as a large Instant Message; 

delivering an Instant Message as a (concatenated) Short Message in the terminating network; and 

submitting an Instant Message as a (concatenated) Short Message in the originating network. 

In addition to the procedures specified in subclause 6.1, the IP-SM-GW shall support the procedures specified in 
subclause 5.7 of 3GPP TS 24.229[3]. 

The IP-SM-GW handles the following messages for SM to IM interworking: 

receiving a SIP REGISTER request, as described in subclause 6.1.2; 

receiving a routing information query as described in subclause 6.1.3.1; 

- receiving an SMS-DELIVER (MT-FORWARD -SHORT-MESS AGE) as described in subclause 6. 1 .4.2; 
sending a SIP MESSAGE request as described in subclause 6.1.4.3.1; 

sending a SIP INVITE request as described in subclause 6.1.4.3.2; and 

- sending an SMS-DELIVER-REPORT as described in subclause 6. 1 .4.4. 
The IP-SM-GW handles the following messages for IM to SM interworking: 

- sending MAP-SEND-ROUTING-INFO-FOR-SM as described in subclause 6.1.3.2; 
receiving a SIP MESSAGE request as described in subclause 6.1.5.2 and subclause 6.1.6.2; 

- sending an SMS-DELIVER (MT-FORWARD-SHORT-MESSAGE) as described in subclause 6.1.5.3; 

- sending an SMS-SUBMIT (MO-FORWARD-SHORT-MESSAGE) as described in subclause 6.1.6.3; 
receiving an SMS-DELIVER-REPORT as described in subclause 6.1.5.4; 

- receiving an SMS-SUBMIT-REPORT (MO-FORWARD-SHORT-MESSAGE-ACK) as described in 
subclause 6.1.6.4; 

- receiving an SMS-STATUS-REPORT (MT-FORWARD-SHORT-MESSAGE) as described in 
subclause 6.1.6.5; and 

sending a SIP MESSAGE containing an IMDN as described in subclause 6.1.5.5 and subclause 6.1.6.6. 

6.1 .2 Notification about registration status and UE capabilities 

Upon receipt of a third-party REGISTER request, the IP-SM-GW shall: 

send a 200 (OK) response for the REGISTER request; 

subscribe to the reg event package for the public user identity registered at the user's registrar (S-CSCF) as 
described in 3GPP TS 24.229 [3]; and 

if the MSISDN is received in the message body of the REGISTER request within the <service-info> XML 
element, then store the MSISDN. 

Upon receipt of a NOTIFY request the IP-SM-GW shall store the information about the UE registration status and its 
ability for receiving Instant Messages, i.e. if the public user identity has a contact registered with the ability to receive 
Instant Messages. 

NOTE 1 : The ability of an UE to receive Instant Messages is included in the Contact header of the REGISTER 
request as described in OMA-TS-SIMPLE_IM [4]. 

NOTE 2: The IP-SM-GW will also receive information about the ability of the UE to receive Short Messages over 
IP as defined in 3GPP TS 24.341 [5]. 
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6.1 .3 Handling of routing information 

6.1 .3.1 Answering routing information query 

The IP-SM-GW shall answer the routing information query which is received from the HSS/HLR as described in 
3GPPTS 24.341 [5]. 

6.1 .3.2 Querying of routing information 

To retrieve the routing information needed for routing the translated Short Message(s) to the servicing MSC or SGSN, 
the IP-SM-GW shall send the MAP-SEND-ROUTING-INFO-FOR-SM message to HSS/HLR as described in 
3GPP TS 29.002 [7]. The IP-SM-GW shall include the following information in the MAP-SEND-ROUTING-INFO- 
FOR-SM message: 

a) Invoke-ID parameter set in accordance with 3GPP TS 29.002 [7]; 

b) MSISDN parameter set to the address of the associated SIP MESSAGE receiver retrieved as part of the 
subscriber data from the HSS at registration by the IP-SM-GW or locally configured in the IP-SM-GW; 

c) SM-RP-PRI parameter set in accordance with 3GPP TS 29.002 [7]; 

d) Service Centre Address parameter set to the address of the IP-SM-GW; 

e) SM-RP-MTI parameter set to (SMS DeHver); 

f) SM-RP-SMEA parameter set based on the value of the P-Asserted-Identity header in the Instant Message if the 
P-Asserted-Identity header contains a E. 164 address; and 

g) GPRS Support Indicator parameter set to indicate that IP-SM-GW supports GPRS specific procedure of combine 
delivery of Short Message via MSC and/or via the SGSN in accordance with 3GPP TS 29.002 [7]. 

6.1 .4 Delivering Short Message(s) as an Instant Message 

6.1.4.1 General 

This section describes the procedure when the IP-SM-GW located in the terminating network interworks Short 
Message(s) to an Instant Message. 

IP-SM-GW procedures at the reception of the Short Message are described in subclause 6. 1 .4.2. 

The creation of the IM is described in subclause 6.1.4.3. 

The creation of the Short Message delivery report is described in subclause 6.1.4.4. 

6.1 .4.2 Receiving of SMS-DELIVER 

When the IP-SM-GW in the terminating networks receives a Short Message from the SMS-GMSC, it shall: 

1) determine if service level interworking is needed for the served user (in SM-RP-DA), i.e. if the served user is 
subscribed for service level interworking and if multiple options are available to deliver the Short Message, then 
user preference or operator policy indicates priority to receive a Short Messages as an Instant Message; and 

2) determine if service level interworking is allowed for the received Short Message. Annex A specifies the transfer 
protocol level criteria that disallow service level interworking. 

The procedure when service level interworking is not allowed is described in subclause 6.1.4.5 

If service level interworking for the received SM is not needed, the IP-SM-GW shall: 

a) attempt to deliver the Short Message over CS/PS; 

b) perform transport level interworking, as described in 3GPP TS 24.341 [5]; or 
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c) create a delivery report indicating failure. 

If the received Short Message is the first segment of the concatenated Short Message and the IP-SM-GW decides to use 
service level interworking, the IP-SM-GW shall store and acknowledge all segments except the last segment of the 
concatenated Short Message. When the IP-SM-GW receives the last segment of the concatenated Short Message and 
the full length of the received concatenated Short Message in Instant Message format is less than the allowed message 
length of an Instant Message, the IP-SM-GW shall create an Instant Message that includes the concatenated Short 
Message in accordance with subclause 6.1.4.3.1. 

NOTE: The allowed message length of an Instant Message is defined in IETF RFC 3428 [8]. 

If the message length of the user generated Short Messages in IM format is greater than the allowed message length of 
an Instant Message and the IM user has registered the capability to receive Instant Messages, the procedure shall be in 
accordance with subclause 6.1.4.3.2. 

6.1 .4.3 Sending of Instant Message 

6.1 .4.3.1 Sending of the Instant Message in a SIP MESSAGE Request 

After receiving either a single Short Message within a MT_FORWARD_SHORT_MESSAGE or a full set of 
concatenated Short Messages not exceeding the size limit of a SIP MESSAGE based Instant Message that is to be 
delivered as an Instant Message, the IP-SM-GW shall send a SIP MESSAGE request applying the related procedures 
for an AS acting as an originating UA as defined in subclause 5.7.3 in 3GPP TS 24.229 [3]. In addition, the IP-SM-GW 
shall include in the SIP MESSAGE request: 

a) the Request URI set to a Tel URI or a SIP URI corresponding to the MSISDN of the recipient. The IMSI 
received in the SM-RP-DA in the MT_FORWARD_SHORT_MESSAGE which corresponds to the MT 
Correlation ID previously created when the SRI message was received, is used to obtain the MSISDN; 

b) the P- Asserted Identity header field set to a Tel URI based on TP-OA parameter received in 
MT_FORWARD_SHORT_MESSAGE(SMS-DELIVER); 

c) the appropriate MIME type(s) in the Content-Type header field; 

d) an Accept-Contact header field with the IM feature-tag "H-g.oma.sip-im"; 

e) a User- Agent header field to indicate the IM release version as specified in OMA-TS-SIMPLE_IM [4]; 

f) a Request-Disposition header field with the value "no-queue", as specified in RFC 3841 [13], in order to ensure 
the SIP MESSAGE is not queued for delivery if the recipient is temporarily unreachable; and 

g) the contents of the Body set to the contents of the Short Message(s) formatted in appropriate MIME type based 
on received content in SM. 

The IP-SM-GW shall send the SIP MESSAGE request to the S-CSCF. 

6.1 .4.3.2 Sending of a large Instant Message 

After receiving a full set of concatenated Short Messages exceeding the size limit of a SIP MESSAGE based Instant 
Message, the IP-SM-GW shall send a INVITE request applying the related procedures for an AS acting as an 
originating UA as defined in subclause 5.7.3 in 3GPP TS 24.229 [3]. In addition. The IP-SM-GW shall include in the 
INVITE request: 

a) an Accept-Contact header field with the IM feature-tags "H-g.oma.sip-im" and "H-g.oma.sip-im.large-message"; 

b) a User- Agent header field to indicate the IM release version as specified in OMA-TS-SIMPLE_IM [4]; 

c) in the Contact header field, the IM feature-tag "H-g.oma.sip-im"; 

d) the Request-URI set to the public user identity deduced from the information in SM-RP-DA; 

e) the P- Asserted Identity header field set to a Tel URI based on TP-OA parameter received in 
MT FORWARD SHORT MESSAGE; 
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f) a Request-Disposition header field with the value "no-queue", as specified in RFC 3841 [13], in order to ensure 
the SIP INVITE is not queued for delivery if the recipient is temporarily unreachable; and 

g) in the SDP, the direction attribute set to a=sendonly as described in OMA-TS-SIMPLE_IM [4]. 

The IP-SM-GW shall send the INVITE request to the S-CSCF. 

Upon receipt of a 2XX SIP reponse to the INVITE request, the IP-SM-GW shall send MSRP SEND request(s) 
containing the content of the concatenated Short Messages as described in OMA-TS-SIMPLE_IM [4]. 

Upon receipt of corresponding response for the last chunk of MSRP SEND request, e.g. 200 OK, the IP-SM-GW shall 
generated a BYE request to release the session as in 3GPP TS 24.229 [3]. 

6.1 .4.4 Sending of SMS-DELIVER-REPORT 

6.1.4.4.1 Common Procedures 

If the IP-SM-GW decided to send SMS-DELIVER-REPORT, it shall send the MT-FORWARD-SHORT-MESSAGE- 
ACK message to the SMS-GMSC in accordance with 3GPP TS 29.002 [7] and 3GPP TS 23.040 [2] with the following 
information: 

Invoke Id parameter set in accordance with 3GPP TS 29.002 [7]; 

If the received SIP response is not a 2XX response, then the value of the User error parameter shall be mapped 
from the SIP response Status Code as described in Table 6.1.4.4.1.1; 

NOTE 1 : If the received SIP response is a 2XX response then the User error parameter is not contained in the MT- 
FORWARD-SHORT-MESSAGE-ACK message. 
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Table 6.1.4.4.1.1 : Mapping from Status Code to User error parameter 



SIP response Status Code 


Value of the user error parameter 


3XX 


System Failure 


5XX 


System Failure 


400 Bad Request 


System Failure 


401 Unauthorized 


Illegal Subscriber indicates that 
delivery of the mobile terminated 
Short l\/lessage failed because the 
mobile station failed authentication 


402 Payment Required 


System Failure 


403 Forbidden 


System Failure 


404 Not Found 


Unidentified subscriber 


405 IVIethod Not Allowed 


System Failure 


406 Not Acceptable 


System Failure 


407 Proxy authentication required 


Illegal Subscriber indicates that 
delivery of the mobile terminated 
Short l\/lessage failed because the 
mobile station failed authentication 


408 Request Timeout 


System Failure 


410 Gone 


System Failure 


413 Request Entity too long 


System Failure 


414 Request-URI too long 


System Failure 


415 Unsupported IVIedia type 


System Failure 


416 Unsupported URI scheme 


System Failure 


420 Bad Extension 


System Failure 


421 Extension required 


System Failure 


423 Interval Too Brief 


System Failure 


433 Anonymity Disallowed.) 


System Failure 


480 Temporarily Unavailable 


Absent Subscriber SIVI 


481 Call/Transaction does not exist 


System Failure 


482 Loop detected 


System Failure 


483 Too many hops 


System Failure 


484 Address Incomplete 


System Failure 


485 Ambiguous 


System Failure 


486 Busy Here 


Subscriber busy for IVIT SI\/IS 


487 Request terminated 


System Failure 


488 Not acceptable here 


System Failure 


493 Undecipherable 


System Failure 


600 Busy Everywhere 


Subscriber busy for MT SI\/IS 


603 Decline 


Subscriber busy for MT SI\/IS 


604 Does not exist anywhere 


Unidentified subscriber 


606 Not acceptable 


System Failure 



- SM-RP-UI set to SMS-DELIVER-REPORT; and 

- the elements of the SMS-DELIVER-REPORT shall be set as described in 3GPP TS 23.040[2] with the following 
information: 

a) TP-MTI element set to OO(SMS-DELIVER-REPORT); 

b) TP-PI element set in accordance with 3GPP TS 23.040[2]; 

c) TP-PID element set to 00000000(SME-to-SME protocol); 

d) TP-DCS element set in accordance with 3GPP TS 23.040[2]; 

e) TP-UDL element set in accordance with 3GPP TS 23.040[2]; 

f) TP-UD element set in accordance with 3GPP TS 23.040[2]; and 

g) If the received SIP response is not a 2XX response, then the value of the TP-FCS element shall be mapped 
from the SIP response Status Code as described in Table 6.1.4.4.1.2. 

NOTE 2: If the received SIP response is a 2XX response then the TP-FCS element is not contained in the SMS- 
DELIVER-REPORT. 
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Table 6.1.4.4.1.2: Mapping from Status Code to TP-FCS element 



SIP response Status Code 


Value of the TP-FCS element 


3XX 


FF Unspecified error cause 


5XX 


FF Unspecified error cause 


400 Bad Request 


FF Unspecified error cause 


401 Unauthorized 


FF Unspecified error cause 


402 Payment Required 


FF Unspecified error cause 


403 Forbidden 


FF Unspecified error cause 


404 Not Found 


FF Unspecified error cause 


405 IVIethod Not Allowed 


FF Unspecified error cause 


406 Not Acceptable 


FF Unspecified error cause 


407 Proxy authentication required 


FF Unspecified error cause 


408 Request Timeout 


FF Unspecified error cause 


410 Gone 


FF Unspecified error cause 


413 Request Entity too long 


FF Unspecified error cause 


414 Request-URI too long 


FF Unspecified error cause 


415 Unsupported IVIedia type 


FF Unspecified error cause 


416 Unsupported URI scheme 


FF Unspecified error cause 


420 Bad Extension 


FF Unspecified error cause 


421 Extension required 


FF Unspecified error cause 


423 Interval Too Brief 


FF Unspecified error cause 


433 Anonymity Disallowed. 


FF Unspecified error cause 


480 Temporarily Unavailable 


FF Unspecified error cause 


481 Call/Transaction does not exist 


FF Unspecified error cause 


482 Loop detected 


FF Unspecified error cause 


483 Too many hops 


FF Unspecified error cause 


484 Address Incomplete 


FF Unspecified error cause 


485 Ambiguous 


FF Unspecified error cause 


486 Busy Here 


D2 Error in MS 


487 Request terminated 


FF Unspecified error cause 


488 Not acceptable here 


FF Unspecified error cause 


493 Undecipherable 


FF Unspecified error cause 


600 Busy Everywhere 


D2 Error in IVIS 


603 Decline 


D2 Error in IVIS 


604 Does not exist anywhere 


FF Unspecified error cause 


606 Not acceptable 


FF Unspecified error cause 



6.1 .4.4.2 Sending of SMS-DELIVER-REPORT after Short Message(s) delivered in a SIP 
MESSAGE Request 

Upon receipt of a 2xx SIP response for the SIP MESSAGE request sent as described in subclause 6. 1 .4.3. 1, the IP-SM- 
GW shall apply the procedures defined in subclause 6.1.4.4.1 to send the MT-FORWARD-SHORT-MESSAGE-ACK 
message to the SMS-GMSC. 

Upon receipt of a non-2xx SIP response for the the INVITE request sent as described in subclause 6.1.4.3.1, the IP-SM- 
GW shall attempt to deliver the Short Message in the next domains as specified in subclause 6. 1 .4.x. If all retries fail, 
the IP-SM-GW shall apply the procedures defined in subclaue 6.1.4.4.1 to send the MT-FORWARD-SHORT- 
MESSAGE-ACK message to the SMS-GMSC. 

6.1 .4.4.3 Sending of SMS-DELIVER-REPORT after concatenated Short Messages 
delivered in a large Instant Message 

Upon receipt of a non-2xx SIP response for the the INVITE request sent as described in subclause 6. 1 .4.3.2, the IP-SM- 
GW shall attempt to deliver the Short Message in the next domains as specified in subclause 6. 1 .4.6. If all retries fail, 
the IP-SM-GW shall apply the procedures defined in subclaue 6.1.4.4.1 to send the MT-FORWARD-SHORT- 
MESSAGE-ACK message for the last segment of the concatenated Short Messages to the SMS-GMSC. 

Upon receipt of a non-200 response for the MSRP SEND request sent as described in subclause 6.1.4.3.2, the IP-SM- 
GW shall attempt to deliver the Short Message in the next domains as specified in subclause 6. 1 .4.6. If all retries fail, 
the IP-SM-GW shall apply the procedures defined in subclaue 6.1.4.4.1 to send the MT-FORWARD-SHORT- 
MESSAGE-ACK message for the last segment of the concatenated Short Messages to the SMS-GMSC. In addition, the 
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User error parameter shall be set to "System Failure" and in SMS -DELI VER-REPORT the TP-FCS element shall be set 
to "FF Unspecified error cause". 

Upon receipt of a 2xx SIP response for the BYE request sent as described in subclause 6. 1.4.3.2, the IP-SM-GW shall 
apply the procedures defined in subclause 6.1.4.4.1 to send the MT-FORWARD-SHORT-MESSAGE-ACK message 
for the last segment of the concatenated Short Messages to the SMS-GMSC. 

Upon receipt of a non-2xx SIP response for the the BYE request sent as described in subclause 6.1.4.3.2, the IP-SM- 
GW shall attempt to deliver the Short Message in the next domains as specified in subclause 6. 1 .4.6. If all retries fail, 
the IP-SM-GW shall apply the procedures defined in subclaue 6.1.4.4.1 to send the MT-FORWARD-SHORT- 
MESSAGE-ACK message for the last segment of the concatenated Short Messages to the SMS-GMSC 

6.1 .4.5 Procedure when delivery of a Short Message as Instant Message is not 
allowed 

If any one of the criteria specified in Appendix B indicate that service level interworking of a Short Message is not 
allowed then the IP-SM-GW shall: 

- send an MT-FORWARD-SHORT-MESSAGE-ACK message to the SMS-GMSC in accordance with 
3GPP TS 29.002 [7] and 3GPP TS 23.040 [2] and a REPORT-SM-DELIVERY- STATUS message to the 
HLR/HSS as described in 3GPP TS 29.002 [7], if the service level interworking was the last option to for Short 
Message delivery; or 

attempt to deliver the Short Message without applying service level interworking according to operator policy, as 
described in 3GPP TS 23.040 [2] and 3GPP TS 24.341 [5]. 

6.1 .4.6 Retry after unsuccessful delivery of Short Message 

If the IP-SM-GW receives an error response when delivering a Short Message in one domain (circuit switched domain, 
packet switched domain or IMS domain), then based on operator policy, the IP-SM-GW shall attempt to deliver the 
Short Message in the next domain in its sequence of priority for retries. 

If all retries fail, the IP-SM-GW shall send a MT-FORWARD-SHORT-MESSAGE-ACK message to the SMS-GMSC 
in accordance with 3GPP TS 29.002[7] and 3GPP TS 23.040[2] and a REPORT-SM-DELIVERY- STATUS message to 
the HLR/HSS as described in 3GPP TS 29.002 [7]. 

6.1 .5 Delivering an Instant Message as a (concatenated) Short Message 
in the terminating network 

6.1.5.1 General 

This section describes the procedure when the IP-SM-GW located in the terminating network interworks an Instant 
Message to Short Message(s). 

IP-SM-GW procedures at the reception of the IM are described in subclause 6.1.5.2 

The creation and the delivery of a Short Message or concatenated Short Messages are described in subclause 6.1.5.3. 

IP-SM-GW procedures at the reception of the Short Message delivery report are described in subclause 6.1.5.4. 

The creation of delivery notification is described in subclause 6.1.5.5. 

NOTE: Interworking for Large Message mode messaging and for Session Mode messaging as defined in OMA- 
TS-SIMPLE_IM [4] is out of scope of this specification. 

6.1 .5.2 Receiving of the Instant Message in a SIP MESSAGE Request 

Upon receipt of a SIP MESSAGE request including an Instant Message in the terminating side, the IP-SM-GW shall: 

1) check the recipient user's preferences, the current UE capability and operator policy before delivering the 

message. If operator policy mandates interworking or the recipient"s preference is to receive an Instant Message 
as a Short Message over CS/PS, the IP-SM-GW shall deliver the Instant Message as a Short Message over 
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CS/PS, If the UE of the Instant Message recipient is capable of accepting SMSIP MESSAGE as defined in 
3GPP TS 24.341 [5] and operator policy mandates interworking or the recipient"s preference is to receive the 
message as a Short Message as a Short Message over IMS, the IP-SM-GW shall deliver the Instant Message as a 
Short Message over IMS; and 

2) check if it is possible to interwork the IM to an SM. 

If the IP-SM-GW decided to interwork the IM to a Short Message (or concatenated Short Messages) the IP-SM-GW 
shall: 

1) if the CPIM body of the received SIP MESSAGE request includes a Disposition-Notification header with value 
"positive-delivery" or "negative-delivery" (i.e. the IM sender requests the Instant Message Delivery Notification) 
then store the values of the MESSAGE-ID Header contained in the CPIM body; and 

2) proceed as described in subclause 6.1.5.3. 

6.1 .5.3 Sending of SMS-DELIVER (over CS/PS or IP) 

6.1.5.3.1 General 

Upon receipt of an Instant Message that is to be delivered as a Short Message over CS/PS, the IP-SM-GW shall query 

the routing information from HSS as described in subclause 6.1.3.2 then send the 

MT_FORWARD_SHORT_MESSAGE to the MSC or SGSN as described in 3GPP TS 29.002 [7] and 

3GPP TS 23.040 [2]. The MT_FORWARD_SHORT_MESSAGE shall be set as described in subclauses 6.1.5.3.2 and 

6.1.5.3.3. 

Upon receipt of an Instant Message that is to be delivered as a Short Message over IMS, the IP-SM-GW shall send the 
SMSIP MESSAGE containing RP-DATA message in the body to the S-CSCF as described in 3GPP TS 24.341 [5] and 
3GPP TS 24.011 [9]. The SMSIP MESSAGE shall be set as described in subsclauses 6.1.5.3.2 and 6.1.5.3.4. 

6.1.5.3.2 Common Procedures 

Both the SM-RP-UI parameter of the MT_FORWARD_SHORT_MESSAGE and the RP-User Data element of the RP- 
DATA message in the SMSIP MESSAGE body shall be set to SMS-DELIVER. And the elements of SMS-DELIVER 
message shall be set in accordance with 3GPP TS 23.040 [2], with the following information: 

a) TP-MTI element set to 00 (SMS-DELIVER); 

b) TP-MMS element set in accordance with 3GPP TS 23.040 [2]; 

NOTE 1 : For example, for concatenated Short Messages, TP-MMS would be set to while there are more 
messages to send. 

c) TP-RP element set to (TP -Reply-Path parameter is not set in this SMS-DELIVER); 

d) TP-UDHI element set in accordance with 3GPP TS 23.040 [2]; 

e) TP-SRI element shall be set to 1, if the SIP MESSAGE contains in a CPIM body a Disposition-Notification 
header with the value of "positive-delivery" or "negative-delivery" (i.e. the SIP MESSAGE sender requests the 
Instant Message Delivery Notification). Otherwise, the TP-SRI element shall be set to 0; 

f) if the SIP MESSAGE request contains the privacy header with "header" or "user" or "id" and the operator policy 
allows sending of anonymous SMS, the value of TP-OA element set to an anonymous value. Setting an address 
field to an anonymous value is described in annex B. If the SIP MESSAGE request does not contain the privacy 
header, the value of the TP-OA element set based on the value of the P-Asserted-Identity header in the Instant 
Message if the P-Asserted-Identity header contains a E.164 address; 

NOTE 2: If no E. 164 address is present in the P-Asserted-Identity header, the value of the TP-OA element will be 
implementation dependant. 

g) TP-PID element set to 00000000 (SME-to-SME protocol); 

h) TP-DCS element set in accordance with 3GPP TS 23.040 [2]; 
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i) TP-SCTS element set to time when the IP-SM-GW received the Instant Message; 

j) TP-UDL element set in accordance with 3GPP TS 23.040 [2]; and 

k) TP-UD element set based on the content of Instant Message body. 

If the content of the body in Short Message format is greater than the allowed message length of a Short Message, then 
the IP-SM-GW shall send concatenated Short Messages. 

NOTE 3: In case of receiving MT_FORWARD_SHORT_MESSAGE_ACK message with the SM-RP-UI 

parameter set to value SMS-DELIVER-REPORT, containing the User error parameter for one segment of 
the concatenated Short Message, the default action of the IP-SM-GW is not to send any remaing segment. 

3GPP TS 23.040 [2] specifies that a Short Message supports GSM 7-bit and UCS2 encoded text while an Instant 
Message may support different text types as defined in 3GPP TS 26.141 [17]. The IP-SM-GW shall reformat the 
received Instant Message text into an appropriate text type supported for Short Messages. 

6.1 .5.3.3 Sending of SMS-DELIVER over CS/PS 

The parameters of the MT_FORWARD_SHORT_MESSAGE shall be set as described in 3GPP TS 29.002 [7], with the 
following information: 

Invoke-ID parameter set in accordance with 3GPP TS 29.002 [7]; 

- SM-RP-DA element set to the address associated with the SIP MESSAGE receiver; 

- SM-RP-OA element set to the address of the IP-SM-GW; 

More Messages To Send parameter set in accordance with 3GPP TS 29.002 [7]; and 

NOTE: For example, for concatenated Short Messages, More Messages To Send would be set to while there are 
more messages to send. 

- SM-RP-UI parameter set to SMS-DELIVER. 

6.1 .5.3.4 Sending of SMS-DELIVER over IP 

The IP-SM-GW shall send the SMSIP MESSAGE as described in 3GPP TS 24.341 [5] with the following exceptions: 

the Request-URI mapped from the Request-URI of the associated SIP MESSAGE request; and 

the body of the request shall contain an RP-D ATA message. The elements of the RP-DATA message shall be set 
as described in 3GPP TS 24.01 1 [9], with the following information: 

a) RP -Message Type element set to 001 (network to MS); 

b) RP -Message Reference element set in accordance with 3GPP TS 24.01 1 [9]; 

c) RP -Originator Address element set to the address of the IP-SM-GW; and 

d) RP-User Data set to SMS-DELIVER. 

6.1 .5.4 Receiving of SMS-DELIVER-REPORT (over CS/PS or IP) 

6.1 .5.4.1 Receiving of SMS-DELIVER-REPORT over CS/PS 

Upon receipt of MT_FORWARD_SHORT_MESSAGE_ACK message with the SM-RP-UI parameter set to value 
SMS-DELIVER-REPORT, and if the associated SIP MESSAGE request received before was dehvered as a single 
Short Message, the IP-SM-GW shall 

send a 200(OK) response to the associated SIP MESSAGE sender, if the 

MT_FORWARD_SHORT_MESSAGE_ACK message does not contain the User error parameter. If the 
associated SIP MESSAGE request received before contains in a CPIM body a Disposition-Notification header 



ETSI 



3GPP TS 29.31 1 version 8.2.0 Release 8 



18 



ETSI TS 129 311 V8.2.0 (2011-10) 



with value "positive-delivery", the IP-SM-GW shall send the Instant Message Delivery Notification with a 
"delivered" indication to the associated SIP MESSAGE sender; or 

attempt deliver the Short Message in the next domains as specified in subclause 6.1.5.6, if the 
MT_FORWARD_SHORT_MESSAGE_ACK message contains the User error parameter. If all retried fail, the 
IP-SM-GW shall send a Status-Code 4xx or 5xx response. The Status code to be sent is determined by 
examining the value of the User error parameter. Table 6.1.5.4.1.1 specifies the mapping of the User error 
parameter as described in 3GPP TS 29.002 [7], to SIP response status codes. If the associated SIP MESSAGE 
request received before contains in a CPIM body a Disposition-Notification header with value "negative- 
delivery", the IP-SM-GW shall send the Instant Message Delivery Notification with a "failed" indication to the 
associated SIP MESSAGE sender. 

Upon receipt of MT_FORWARD_SHORT_MESSAGE_ACK message with the SM-RP-UI parameter set to value 
SMS-DELIVER-REPORT, and if the associated SIP MESSAGE request received before was delivered as concatenated 
Short Messages, the IP-SM-GW shall wait for the last MT_FORWARD_SHORT_MESSAGE_ACK message. Then the 
IP-SM-GW shall 

send a 200(OK) response to the associated SIP MESSAGE sender, if none of the 

MT_FORWARD_SHORT_MESSAGE_ACK messages contains the User error parameter. If the associated SIP 
MESSAGE request received before contains in a CPIM body a Disposition-Notification header with value 
"positive-delivery", the IP-SM-GW shall send the Instant Message Delivery Notification with a "delivered" 
indication to the associated SIP MESSAGE sender; or 

attempt deliver the Short Message in the next domains as specified in subclause 6.1.5.6, if at least one of 
MT_FORWARD_SHORT_MESSAGE_ACK messages contains the User error parameter. If all retries fail, the 
IP-SM-GW shall send a Status-Code 4xx or 5xx response to the associated SIP MESSAGE sender. The Status 
code to be sent is determined by examining the value of the User error parameter. Table 6.1.5.4.1.1 specifies the 
mapping of the User error parameter as described in 3GPP TS 29.002 [7], to SIP response status codes. If the 
associated SIP MESSAGE request received before contains in a CPIM body a Disposition-Notification header 
with value "negative-delivery", the IP-SM-GW shall send the Instant Message Delivery Notification with a 
"failed" indication to the associated SIP MESSAGE sender. 

Table 6.1.5.4.1.1 : Mapping from User error parameter to Status code 



Value of the User error parameter 


SIP response Status code 


Unidentified subscriber 


404 Not Found 


Absent Subscriber SIVI 


480 Temporarily unavailable 


Subscriber busy for MI SMS 


486 Busy Here 


Facility Not Supported 


500 Server Internal error 


Illegal Subscriber indicates that 
delivery of the mobile terminated 
Short Message failed because the 
mobile station failed authentication 


500 Server Internal error 


Illegal equipment indicates that 
delivery of the mobile terminated 
Short Message failed because an 
IMEI check failed, i.e. the IMEI was 
blacklisted or not white-listed; 


500 Server Internal error 


System Failure 


500 Server Internal error 


SM Delivery Failure with cause 
"memory capacity exceeded in the 
mobile equipment" 


480 Temporarily unavailable 


SM Delivery Failure with cause 
"protocol error" 


500 Server Internal error 


SM Delivery Failure with cause 
"mobile equipment does not support 
the mobile terminated Short 
Message service" 


500 Server Internal error 


Unexpected Data Value 


500 Server Internal error 


Data Missing 


500 Server Internal error 
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6.1 .5.4.2 Receiving of SMS-DELIVER-REPORT over IP 

Upon receipt of a SMSIP MESSAGE with RP-ACK or RP -ERROR message in the body, the IP-SM-GW shall respond 
with a 202(Accepted) response in accordance with 3GPP TS 24.341 [5]. 

If the SMSIP MESSAGE contains RP-ACK message in the body, and the associated SIP MESSAGE request received 
before contains in a CPIM body a Disposition-Notification header with value "positive-delivery", the IP-SM-GW shall 
send the Instant Message Delivery Notification with a "delivered" indication to the associated SIP MESSAGE sender. If 
the associated SIP MESSAGE request received before was delivered as concatenated Short Messages and all the 
SMSIP MESSAGE contains RP-ACK message in the body for the concatenated Short Messages, the IP-SM-GW shall 
send the Instant Message Delivery Notification with a "delivered" indication to the associated SIP MESSAGE sender. 

If the SIP MESSAGE contains RP-ERROR message in the body, the IP-SM-GW shall attempt deliver the Short 
Message in the next domains as specified in subclause 6.1.5.6. If all retries fail and the associated SIP MESSAGE 
request received before contains in a CPIM body a Disposition-Notification header with value "negative-delivery", the 
IP-SM-GW shall send the Instant Message Delivery Notification with a "failed" indication to the associated SIP 
MESSAGE sender. If the associated SIP MESSAGE request received before was delivered as concatenated Short 
Messages and at least one of the SMSIP MESSAGES contains RP-ERROR message in the body for the concatenated 
Short Messages, the IP-SM-GW shall send the Instant Message Delivery Notification with a "failed" indication to the 
associated SIP MESSAGE sender. 

6.1.5.5 Sending of IMDN 

6.1 .5.5.1 Sending of IMDN after a (concatenated) Short Message delivery over CS/PS 

If the IP-SM-GW decided to send an Instant Message Delivery Notification, it shall act as an originating UA as defined 
in subclause 5.7.3 in 3GPP TS 24.229 [3] to send a SIP MESSAGE request with the following exceptions: 

a) the Request-URI shall contain a public user identity of the stored sender identity of the associated SIP 
MESSAGE; 

b) a User- Agent header field shall indicate the IM release version as specified in OMA-TS-SIMPLE_IM [4]; 

c) the P-Asserted-Identity header shall be mapped from the stored Request-URI of the associated SIP MESSAGE; 

d) an Accept-Contact header field shall contain the IM feature-tag "H-g.oma.sip-im"; 

e) the Content-Type header shall contain "message/imdn-nxml"; and 

f) the body of the request shall contain a CPIM message as defined in OMA-TS-SIMPLE_IM [4], including the 
following information: 

the <message-id> XML element of the IMDN payload shall be set to the value of the stored Message-ID 
header in the CPIM body of the associated SIP MESSAGE request; and 

the <disposition> XML element of the IMDN payload shall be set to <delivery/>. 

6.1 .5.5.2 Sending of IMDN after a (concatenated) Short Message delivery over IP 

If the IP-SM-GW decided to send an Instant Message Delivery Notification, it shall act as a Routeing B2BUA 
AppUcation Server (AS) as defined in subclause 5.7.5 in 3GPP TS 24.229 [3] to send a SIP MESSAGE request with the 
following exceptions: 

a) the Request-URI shall contain a public user identity of the stored sender identity of the associated SIP 
MESSAGE; 

b) the P-Asserted-Identity header shall be set to the value of the stored Request-URI of the associated SIP 
MESSAGE request; 

c) the Accept-Contact header shall contain the IM feature tag "H-g.oma.sip-im"; 

d) the User- Agent header shall indicate the IM release version as specified in OMA-TS-SIMPLE_IM [4]; 

e) the Content-Type header shall contain "message/imdn-nxml"; and 
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f) the body of the request shall contain a CPIM message as defined in OMA-TS-SIMPLE_IM [4], including the 
following information: 

the <message-id> XML element of the IMDN payload which shall be set to the value of the stored Message- 
ID header in the CPIM body of the associated SIP MESSAGE request; and 

the <disposition> XML element of the IMDN payload which shall be set to <delivery/>. 

6.1 .5.6 Retry after unsuccessful delivery of Short Message 

If the IP-SM-GW receives an error response when delivering a Short Message in one domain (circuit switched domain, 
packet switched domain or IMS domain), then based on operator policy, the IP-SM-GW shall attempt to deliver the 
Short Message in the next domain in its sequence of priority for retries. 

If all retries fail, the IP-SM-GW shall send a REPORT-SM-DELIVERY- STATUS message to the HLR/HSS as 
described in 3GPP TS 29.002 [7]. 

6.1 .5.7 Error handling when interworking from Instant Message to Short Message is 
not possible 

When interworking is needed but is not possible, the IP-SM-GW shall send one of the following error responses to the 
sender of the Instant Message: 

If the error is because none of the content in the SIP MESSAGE request is interworkable to a Short Message, 
then the IP-SM-GW shall include a 415 (Unsupported Media Type) response and shall also include an Accept 
header field listing the types of text media supported by SM as described in 3GPP TS 26.141 [16]. For service 
level interworking of Instant Message to Short Message, only text shall be supported. 

Otherwise a 488 (Not Acceptable Here) response shall be returned. 

6.1 .5.8 Partial interworking from Instant Message to Short Message 

If an Instant Message contains other media than text content, the IP-SM-GW may remove the unsupported content. 

Based on Operator policy the IP-SM-GW may insert text warning the receiver that non-text content has been removed 
from the message. 

6.1 .6 Submitting an Instant Message as a (concatenated) Short Message 
in the originating network 

6.1.6.1 General 

This section describes the procedure when the IP-SM-GW located in the originating network interworks an Instant 
Message to a Short Message. 

IP-SM-GW procedures at the reception of the IM are described in subclause 6. 1.6.2. 

The creation of a (concatenated) Short Message is described in subclause 6.1.6.3. 

IP-SM-GW procedures at the reception of the Short Message submit report are described in subclause 6.1.6.4. 

IP-SM-GW procedures at the reception of the Short Message status report are described in subclause 6.1.6.5. 

The creation of delivery notification is described in subclause 6.1.6.6. 

NOTE: Interworking for Large Message mode messaging and for Session Mode messaging as defined in OMA- 
TS-SIMPLE_IM [4] is out of scope of this specification. 
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6.1 .6.2 Receiving of the Instant Message in a SIP MESSAGE Request 

Upon receipt of a SIP MESSAGE request including an Instant Message, the IP-SM-GW shall attempt service level 
interworking if operator policy mandates interworking or the IP-SM-GW cannot find a SIP address for the recipient. 

If IP-SM-GW determined that service level interworking needed, then the IP-SM-GW shall: 

1) check if the message originator is authorized for service level interworking; and 

NOTE: It can be assumed that all subscribers are authorized for service level interworking if interworking is 
mandated by operator policy. 

2) check if the service level interworking is possible. 

If IP-SM-GW decided to submit the Instant Message as a Short Message, then the IP-SM-GW shall: 

1) respond with a 202(Accepted) response in accordance with 3GPP TS 24.229 [3]; 

2) store the values of the Request-URI, the P-Asserted-Identity header and the MESSAGE-ID Header contained in 
the CPIM body, if the received SIP MESSAGE request includes a CPIM body and a Disposition-Notification 
header with value "positive-delivery" or "negative-delivery" (i.e. the SIP MESSAGE sender requests the Instant 
Message Delivery Notification); and 

3) proceed as described in subclause 6.1.6.3. 

6.1 .6.3 Sending of SMS-SUBMIT over CS/PS 

To submit a Short Message to the SC, the IP-SM-GW shall send MO_FORWARD_SHORT_MESSAGE as described 
in 3GPP TS 29.002 [7] and 3GPP TS 23.040 [2]. In addition, for the information elements listed below, the following 
interworking procedures shall apply: 

Invoke-ID pareameter set in accordance with 3GPP TS 29.002 [7]; 

SM-RP-DA parameter set to the address of user"s home network Service Centre configured in the IP-SM-GW, 
or retrieved as part of the subscriber data from the HSS at registration by the IP-SM-GW; 

if the SIP MESSAGE request contains the privacy header with "header" or "user" or "id" and the operator policy 
allows sending of anonymous SM, the value of SM-RP-OA parameter shall be set to an anonymous value. 
Setting an address field to an anonymous value is described in annex B. If the SIP MESSAGE request does not 
contain the privacy header, the value of the SM-RP-OA parameter shall be set based on the value of the P- 
Asserted-Identity or the address retrieved as part of the subscriber data from the HSS at registration by the IP- 
SM-GW; 

- SM-RP-UI parameter set to SMS-SUBMIT; and 

- the elements of the SMS-SUBMIT message shall be set as described in 3GPP TS 23.040 [2] subclause 9.2.2, 
with the following information: 

a) TP-MTI element set to 01 (SMS-SUBMIT); 

b) TP-RD element set to 1 (Instruct the SC to reject an SMS SUBMIT for an SM still held in the SC which has 
the same TP MR and the same TP DA as the previously submitted SM from the same OA.); 

c) if the SIP MESSAGE request contains an Expires header with a non-zero value, the value of TP VPF element 
shall be set according to the TP VP element. Otherwise, the value of TP VPF element shall be set to 00 (TP 
VP field not present); 

d) TP VP element set based on the Expires header value and the optional Date header value; 

e) TP-UDHI element set in accordance with 3GPP TS 23.040 [2]; 

f) if the SIP MESSAGE contains in a CPIM body a Disposition-Notification header with the value of "positive- 
delivery" or "negative-delivery" (i.e. the SIP MESSAGE sender requests the Instant Message Delivery 
Notification), the value of TP SRR element shall be set to 1 (A status report is requested). Otherwise, the 
value of TP-SRR element shall be set to (A status report is not requested); 
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g) TP-MR element set in accordance with 3GPP TS 23.040 [2]; 

h) TP-RP element set to (TP Reply Path parameter is not set in this SMS SUBMIT); 

i) TP-DA element set based on the value of the Request-URJ in the Instant Message as long as the Request-URJ 
contains a E. 164 address; 

j) TP-PI element set to 00000000 (SME-to-SME protocol); 

k) TP-DCS element set in accordance with 3GPP TS 23.040 [2]; 

1) TP-UDL element set in accordance with 3GPP TS 23.040 [2]; and 

m) TP-UD element set based on the content of Instant Message body. 

If the content of the body in Short Message format is greater than the allowed message length of a Short Message, then 
the IP-SM-GW shall send concatenated Short Messages. 

NOTE: In case of receiving MO_FORWARD_SHORT_MESSAGE_ACK message with the SM-RP-UI 

parameter set to value SMS -SUB MIT-REPORT, containing the User error parameter for one segment of 
the concatenated Short Message, the default action of the IP-SM-GW is not to send any remaing 
segment. 

3GPP TS 23.040 [2] specifies that a Short Message supports GSM 7-bit and UCS2 encoded text while an Instant 
Message may support different text types as defined in 3GPP TS 26.141 [16]. The IP-SM-GW shall reformat the 
received Instant Message text into an appropriate text type supported for Short Messages. 

6.1 .6.4 Receiving of SMS-SUBMIT-REPORT 

Upon receipt of MO_FORWARD_SHORT_MESSAGE_ACK with the SM-RP-UI parameter set to value SMS- 
SUBMIT-REPORT, not containing the User error parameter, and if the associated SIP MESSAGE request received 
before contains in a CPIM body a Disposition-Notification header with value "positive-delivery" or "negative-delivery" 
(i.e. the SIP MESSAGE sender requests the Instant Message Delivery Notification), the IP-SM-GW shall store the 
value of TP Service Centre Time Stamp element. 

Upon receipt of MO_FORWARD_SHORT_MESSAGE_ACK with the SM-RP-UI parameter set to value SMS- 
SUBMIT-REPORT, containing the User error parameter, and if the associated SIP MESSAGE request received before 
contains in a CPIM body a Disposition-Notification header with value "negative-delivery", the IP-SM-GW shall send 
the Instant Message Delivery Notification with a "failed" indication to the associated SIP MESSAGE sender. If the 
associated SIP MESSAGE request received before was delivered as concatenated Short Messages as described in 
subclause 6.1.6.3, and one of the MO_FORWARD_SHORT_MESSAGE_ACK for the concatenated Short Messages 
contains the User error parameter, the IP-SM-GW shall send the Instant Message Delivery Notification with a "failed" 
indication to the associated SIP MESSAGE sender. 

6.1 .6.5 Receiving of SMS-STATUS-REPORT 

Upon receipt of a MT_FORWARD_SHORT_MESSAGE with the SM-RP-UI parameter set to value of SMS-STATUS- 
REPORT, the IP-SM-GW shaU: 

retrieve the TP-Service-Centre-Time-Stamp and TP-Recipient-Address, then find the associated SIP MESSAGE 
request instance containing the stored TP-Service-Center-Time-Stamp and SM-RP-Originating Address element 
with the same value; and 

- if the SMS-STATUS-REPORT matchs one associated SIP MESSAGE request, send an Instant Message 
Delivery Notification or discard the SMS-STATUS-REPORT as described in Table 6.1.6.5.1; or 

- wait for the last SMS-STATUS-REPORT, if the associated SIP MESSAGE request was dehvered as 
concatenated Short Messages as described in subclause 6.1.6.3. If all SMS-STATUS-REPORTs for concatenated 
Short Messages contains the TP-Status element set to "00000000" and the associated SIP MESSAGE request 
contains in a CPIM body a Disposition-Notification header with value "positive-delivery", the IP-SM-GW shall 
send the Instant Message Delivery Notification with a "delivered" indication to the associated SIP MESSAGE 
sender. If at least one of SMS-STATUS-REPORT for concatenated Short Messages contains the TP-Status 
element set between "00000001" and "00011111" or between "01000000" and "11111111", and the associated 
SIP MESSAGE request contains in a CPIM body a Disposition-Notification header with value "negative- 
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delivery", the IP-SM-GW shall send the Instant Message Delivery Notification with a "failed" indication to the 
associated SIP MESSAGE sender. 

Table 6.1 .6.5.1 : Process of the received SMS-STATUS-REPORT 



The value of TP-Status element of 
SMS-STATUS-REPORT 


The parameter of the Disposition- 
Notification header in the CPIM 
body of the associated SIP 
MESSAGE 


Process of the IP-SM-GW 


"00000000" 


Include "positive-delivery" 


Shall send Instant Message Delivery 

Notification to the associated SIP 

MESSAGE sender 


"OOOOOOOr'to "00011111" or 
"01 000000" to "11111111" 


Include "negative-delivery" 


Shall send Instant Message Delivery 

Notification to the associated SIP 

MESSAGE sender 


"00100000" to "00111111" 


Include "positive-delivery" or 
'negative-delivery' 


May discard the SMS-STATUS- 
REPORT 


"00000000" 


Not include "positive-delivery" 


May discard the SMS-STATUS- 
REPORT 


"00000001" to "00011111" or 
"01 000000" to "11111111" 


Not include "negative-delivery" 


May discard the SMS-STATUS- 
REPORT 



6.1 .6.6 Sending of IMDN (both for SUBMIT-REPORT and STATUS-REPORT) 

If the IP-SM-GW decided to send an Instant Message Delivery Notification, it shall act as an originating UA as defined 
in subclause 5.7.3 in 3GPP TS 24.229 [3] to send a SIP MESSAGE request with the following exceptions: 

a) the Request-URI shall contain a public user identity of the stored sender identity of the associated SIP 
MESSAGE; 

b) the P-Asserted-Identity header shall be set to the value of the stored Request-URI of the associated SIP 
MESSAGE request; 

c) the Accept-Contact header shall be set with the IM feature tag "H-g.oma.sip-im"; 

d) the User- Agent header which shall be set with the IM release version as specified in OMA-TS-SIMPLE_IM [4]; 

e) the Content-Type header shall contain "message/imdn-nxml"; and 

f) the body of the request shall contain a CPIM message as defined in OMA-TS-SIMPLE_IM [4], including the 
following information: 

the <message-id> XML element of the IMDN payload shall be set to the value of the stored Message-ID 
header in the CPIM body of the associated SIP MESSAGE request; and 

the <disposition> XML element of the IMDN payload shall be set to <delivery/>. 

6.1 .6.7 Error handling when interworking from Instant IVIessage to Short IVIessage is 
not possible 

When interworking is needed but is not possible, the IP-SM-GW shall send one of the following error responses to the 
sender of the Instant Message: 

If the error is because none of the content in the SIP MESSAGE request is interworkable to a Short Message, 
then the IP-SM-GW shall send a 415 (Unsupported Media Type) response and shall also include an Accept 
header field listing the types of text media supported by SM as decribed in 3GPP TS 26.141 [16]. For service 
level interworking of Instant Message to Short Message, only text shall be supported. 



Otherwise a 488 (Not Acceptable Here) response shall be returned. 



6.1.6.8 



Partial interworking from Instant Message to Short Message 



If an Instant Message contains other media than text content, the IP-SM-GW may remove the unsupported content. 
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Based on Operator policy the IP-SM-GW may insert text warning the receiver that non-text content has been removed 
from the message. 
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Annex A (normative): 

Impacts of TP parameters in a Short IVIessage on service 

level interworking 



A.1 Scope 



The present annex defines how the TP parameters in a short message impact the possibility of service level 
interworking. If any of the criteria defined in this annex indicate that service level interworking is not allowed then the 
procedure in subclause 6. 1 .4.5 shall be followed. 



A.2 TP-Data-Coding-Scheme (TP-DCS) 

Table A.2. 1 describes whether or not service level interworking is allowed based on the value of the TP-DCS parameter 
of a Short Message. 

Table A.2.1 : Impact of the TP-DCS parameter on service level interworking 



TP-DCS 
Coding 
Group 

TP-DCS 
Bits 7..4 


TP-DCS Description 

Depends on the use of TP-DCS bits 3..0 


Service Level 

Interworking 

allowed 

(Y/N) 
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TP-DCS 
Coding 
Group 

TP-DCS 
Bits 7..4 


TP-DCS Description 

Depends on the use of TP-DCS bits 3..0 


Service Level 

Interworking 

allowed 

(Y/N) 


OOxx 


General Data Coding indication 
Bits 5..0 indicate the following: 

Bit 5, if set to 0, indicates the text is uncompressed 

Bit 5, if set to 1 , indicates the text is compressed using the compression algorithm 

defined in 3GPP TS 23.042 [14] 


n/a 


Bit 4, if set to 0, indicates that bits 1 to are reserved and have no message class 
meaning 


Y 


Bit 4, if set to 1 , indicates that bits 1 to have a message class meaning:: 






Bit 1 


BitO 


Message Class 








Class 


Y 





1 


Class 1 Default meaning: ME-specific. 


Y 


1 





Class 2 {U)SIM specific message 


N 


1 


1 


Class 3 Default meaning: TE specific 
(see 3GPPTS 27.005 [15]) 


Y 








Bits 3 a 


^6 2 indicate the character set being used, as follows : 






Bit 3 


Bit2 


Character set: 








GSM 7 bit default alphabet 


Y 





1 


8 bit data 


N 


1 





UCS2(16bit) 


Y 


1 


1 


Reserved 


n/a 








NOTE: The special case of bits 7..0 being 0000 0000 indicates the GSM 7 bit default 
alphabet with no message class 


Y 


01 XX 


Message Marked for Automatic Deletion Group 

This group can be used by the SM originator to mark the message ( stored in the ME or 

(U)SIM ) for deletion after reading irrespective of the message class. 

The way the ME will process this deletion should be manufacturer specific but shall be 

done without the intervention of the End User or the targeted application. The mobile 

manufacturer may optionally provide a means for the user to prevent this automatic 

deletion. 

Bit 5..0 are coded exactly the same as Group OOxx 


See Group 
OOxx 


1000.. 1011 


Reserved coding groups 


n/a 


1100 


Message Waiting Indication Group: Discard Message 


N 
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TP-DCS 
Coding 
Group 

TP-DCS 
Bits 7..4 


TP-DCS Description 

Depends on the use of TP-DCS bits 3..0 


Service Level 

Interworking 

allowed 

(Y/N) 




The specification for this group is exactly the same as for Group 1101 , except that: 
after presenting an indication and storing the status, the IVIE may discard the 
contents of the message. 

The IVIE shall be able to receive, process and acknowledge messages in this group, 
irrespective of memory availability for other types of Short IVIessage. 




1101 


Message Waiting Indication Group: Store Message 

This Group defines an indication to be provided to the user about the status of types of 
message waiting on systems connected to the GSM/UMTS PLMN. The ME should 
present this indication as an icon on the screen, or other MM! indication. The ME shall 
update the contents of the Message Waiting Indication Status on the SIM (see 3GPP TS 
51.011 [18]) or USIM (see 3GPP TS 31.102 [17]) when present or otherwise should store 
the status in the ME. In case there are multiple records of EFmwis this information shall be 
stored within the first record. The contents of the Message Waiting Indication Status 
should control the ME indicator. For each indication supported, the mobile may provide 
storage for the Origination Address. The ME may take note of the Origination Address for 
messages in this group and group 1 1 00. 

Text included in the user data is coded in the GSM 7 bit default alphabet. 
Where a message is received with bits 7..4 set to 1 1 01 , the mobile shall store the text of 
the SMS message in addition to setting the indication. The indication setting should take 
place irrespective of memory availability to store the Short Message. 

Bits 3 indicates Indication Sense: 

Bit 3 

Set Indication Inactive 

1 Set Indication Active 

Bit 2 is reserved, and set to 

Bit 1 Bit Indication Type: 

Voicemail Message Waiting 

1 Fax Message Waiting 

1 Electronic Mail Message Waiting 
1 1 Other Message Waiting* 

* Mobile manufacturers may implement the "Other Message Waiting" indication as an 
additional indication without specifying the meaning. 


N 


1110 


Message Waiting Indication Group: Store Message 

The coding of bits 3..0 and functionality of this feature are the same as for the Message 
Waiting Indication Group above, (bits 7..4setto 1101) with the exception that the text 
included in the user data is coded in the uncompressed UCS2 character set. 


N 



A. 3 TP-User-Data Header Information Elements (UDH- 
lE) 

If a Short Message contains a Header in the TP-User-Data field, then the Header may include multiple Information 
Elements. Table A.3.1 describes whether or not service level interworking is allowed based on the occurrence of 
different Information Elements. The Information Elements are listed by Information Element Identifier in the table. 
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Table A.3.1 : Impact of the TP-UDH information elements on service level interworking 



UDH-IEI 
Value 
(hex) 


UDH-IE Description 


Service Level Interworking allowed 

(Y/N) 


00 


Concatenated Short Messages, 8-bit reference number 


Y 


01 


Special SIVIS Message Indication 


N 


02 


Reserved 


n/a 


03 


Value not used to avoid misinterpretation as <LF> 
character 


n/a 


04 


Application port addressing scheme, 8 bit address 


N 


05 


Application port addressing scheme, 16 bit address 


N 


06 


SMSC Control Parameters 


Y 


07 


UDH Source Indicator 


Y 


08 


Concatenated Short Message, 16-bit reference number 


Y 


09 


Wireless Control Message Protocol 


N 


OA 


Text Formatting 


Y 


OB 


Predefined Sound 


Y 


OC 


User Defined Sound (iMelody max 128 bytes) 


Y 


OD 


Predefined Animation 


Y 


OE 


Large Animation (16*16 times 4 = 32*4 =128 bytes) 


Y 


OF 


Small Animation (8*8 times 4 = 8*4 =32 bytes) 


Y 


10 


Large Picture (32*32 = 128 bytes) 


Y 


11 


Small Picture (16*16 = 32 bytes) 


Y 


12 


Variable Picture 


Y 


13 


User prompt indicator 


Y 


14 


Extended Object 


Y 


15 


Reused Extended Object 


Y 


16 


Compression Control 


Y 


17 


Object Distribution Indicator 


Y 


18 


Standard WVG object 


Y 


19 


Character Size WVG object 


Y 


1A 


Extended Object Data Request Command 


Y 


1B-1F 


Reserved for future EMS features (see subclause 3.10) 


n/a 


20 


RFC 822 E-Mail Header 


N 


21 


Hyperlink format element 


Y 


22 


Reply Address Element 


N 


23 


Enhanced Voice Mail Information 


N 


24-6F 


Reserved for future use 


n/a 


70-7F 


(U)SIM Toolkit Security Headers 


N 


80-9F 


SME to SME specific use 


N 


AO-BF 


Reserved for future use 


n/a 


CO-DF 


SC specific use 


N 


EO-FF 


Reserved for future use 


n/a 
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A.4 TP-Protocol-ldentifier (TP-PID) 

Table A.4. 1 describes whether or not service level interworking is allowed based on the value of the TP-PID parameter 
in an SMS-DELIVER. 

Table A.4.1 : Impact of the TP-PID parameter on service level interworking 



TP- 
PID 
Bits 
76 


TP-PID Description 


Service Level 

Interworking 

Allowed 

(Y/N) 


00 


bit 5 indicates telematic interworl<ing: 

If bit 5 has value 1 in an SMS-DELIVER PDU, it indicates that the SME is a telematic device of 
a type which is indicated in bits 4..0. 

If bit 5 has value in an SMS-DELIVER PDU, the value in bits 4..0 identifies the SM-AL 
protocol being used between the SME and the MS. 


Y 


01 


bits 5..0 are used as defined below 






Bit5..0 




000000 


Short IVIessage Type 


Y 


000001 


Replace Short IVIessage Type 1 


Y 


000010 


Replace Short IVIessage Type 2 


Y 


00001 1 


Replace Short IVIessage Type 3 


Y 


000100 


Replace Short IVIessage Type 4 


Y 


000101 


Replace Short IVIessage Type 5 


Y 


000110 


Replace Short IVIessage Type 6 


Y 


0001 1 1 


Replace Short IVIessage Type 7 


Y 


001000..011101 


Reserved 


n/a 


011110 


Enhanced Message Service (Obsolete) 


n/a 


011111 


Return Call Message 


Y 


100000.. 111011 


Reserved 


n/a 


111100 


ANSI-136R-DATA 


N 


111101 


ME Data download 


N 


111110 


ME De-personalization Short Message 


N 


111111 


(U)SIM Data download 


N 








10 


reserved 


n/a 


11 


Assigns bit 0-5 for SC specific use 


undefined 
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Annex B (normative): 
Anonymous SMS 

B.1 Scope 

The present annex defines how the sending party's address (SM-RP-OA parameter in case of SMS-SUBMIT, TP-OA 
element in case of SMS-DELIVER), which is mandatory in SMS, is set to anonymise the sender's identity and to clearly 
indicate that for the receiver of the SMS at the same time. 



B.2 Anonymous address in SIVIS 



To indicate anonymous sender the address field representing the SM-RP-OA parameter in case of an SMS-SUBMIT or 
the TP-OA element in case of SMS-DELIVER should be set as follows: 

length of address is set to 18; 

type of number is set to alphanumerical; 

numbering plan identification is set to ISDN/telephone numbering plan; and 

the address value is set to "Anonymous" with the 7 bit character representation, as the default alphabet defined in 
3GPPTS 23.038 [17]. 

As an alternative, country specific text may be defined with the only restriction that it must fit to the 10 character limit 
of the alphanumerical type. 

The recommended encoding of the "Anonymous" alphanumeric address is shown in Figure B.2-1. 



Octet 

# 


bit 

7 


bit 
6 


bit 

5 


bit 

4 


bit 

3 


bit 

2 


bit 
1 


bit 



Explanation 


1 











1 














length of address parameter (16 semi 
octets) 


2 


1 


1 





1 











1 


ex 

t 


type of num- 
ber 101 indi- 
cates alpha- 
numeric 


Numbering plan 
id: 0001 indicates 
ISDN/telephone 
numbering plan 


3 





1 





















x41 for ASCII 65 of "A" 


4 


1 


1 


1 


1 





1 


1 




"o" x6E for ASCII 110 of "n" 


5 


1 


1 





1 







1 




1 10 of "n" x6F for ASCII 1 11 of 


6 


1 








1 




1 







ASCII 121 of "y" 


x6E for ASCII 


7 





1 


1 







1 


1 




ASCII 109 of "m" x79for 


8 


1 





1 


1 




1 


1 




x6F for ASCII 1 1 1 of "o" x6D for 


9 


1 


1 


1 










1 




x75 for ASCII 117of"u" 


10 





1 


1 


1 








1 






x73 for ASCII 115of"s" 



Figure B.2-1 : Address field with "Anonymous" alphanumeric value 
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